- 4 minutes to read

The BizTalk Logging Agent requires the following prerequisites for your target environment

Unlock seamless, secure BizTalk Server logging and monitoring with Nodinite. On this page, you will:

  • ✅ Ensure you achieve secure, high-performance integration between BizTalk Server and Nodinite
  • ✅ Set up Linked Servers and firewall rules to provide robust data visibility
  • ✅ Configure user rights, SQL permissions, and Active Directory to maintain compliance
  • ✅ Avoid common pitfalls by following clear, actionable guidance
graph LR subgraph "Nodinite App Server" roLoggingService(fal:fa-hard-drive Logging Service) end subgraph "
Nodinite SQL Server" roLoggingService --> |High privileges|roNI roNI(fal:fa-database Nodinite SQL Server Instance) end subgraph "BizTalk SQL Server" roNI --> |Linked Server
Low privileges| roBTMgmtDB(fal:fa-database BizTalkMgmtDb) roNI --> |Linked Server
Low privileges| roBTDTADb(fal:fa-database BizTalkDTADb) end

Diagram: This architecture enables you to achieve secure, high-performance BizTalk logging with Nodinite.

The Logging Service currently hosts the BizTalk Server Logging feature, so you must meet the Prerequisites for that service.

To enable Logging from BizTalk Server, in addition to the Logging Service - Prerequisites, you must also meet the requirements documented on this page.

If you install your BizTalk Server databases (BizTalkMgmtDb and BizTalkDTADb) on remote SQL instances, Nodinite connects to these remote SQL instances using Linked Servers. You must manually add the Linked Servers on your Nodinite SQL instance before you configure and enable Logging.

Note

If you have BizTalkMGMTDb and BizTalkDTADb on different SQL Server instances, you need two Linked Servers.

What Firewall settings are required for enabling Logging from BizTalk Server

In addition to the firewall settings already in place for the Logging Service, you must also enable the ports specified in this section.

To retrieve data from BizTalk Server, the Logging Service fetches data directly from the SQL Instances for BizTalk Server with the BizTalkMsgBoxDb and the BizTalkDTADb database. These databases may exist on different SQL Instances. These may have different sets of ports in use.

  1. The Logging Service connects to the BizTalk Server instances
Port Name Inbound Outbound TCP UDP Comment
53 DNS The Agent needs to know where your other servers/services are (can sometimes optionally be solved with user-defined entries in the hosts file in each Windows server instance), review the following 'Microsoft' user guide
88 Kerberos Review 'Microsoft Kerberos' user guide
135 DTC/RPC This port is shared between many Windows Services
1433/... SQL Server instance ports (multiple) Depends on policies and settings on target environment. Please review the How to configure RPC dynamic port allocation to work with firewalls user guide

Security

User rights

  • Use Domain accounts for best practice. Use local accounts only for single server solutions (Test, QA, DEV, POC....)

    You can use a SQL account (bypassing Kerberos) if the SQL Instance for the BizTalk databases allows for mixed logins. We recommend using Windows accounts. If you use Windows Authentication, you must configure Kerberos properly.

SQL Rights

The account running the Logging Service for BizTalk Server Logging must have the following SQL rights to read events and messages from the BizTalk databases:

SQL Instance(s)

On all SQL instances with the listed BizTalk databases:

  • public - You must have the right to logon to the SQL Instances for BizTalk Server

BizTalkDTADB

  • db_datareader
  • db_ddladmin

BizTalkMGMTDB

  • db_datareader
  • db_ddladmin

Active Directory Configuration

  • For single box solutions, you do not need to configure Windows to enforce the use of the Kerberos security protocol.
  • For distributed solutions, for example when you install Nodinite on one (or more) server(s), and the databases are also located on multiple SQL instances, you must use Kerberos.

For Kerberos to work, you must properly configure Active Directory for all involved Windows Servers:

  • Trusted for delegation
  • All SQL Instances (both physical node names and cluster names) must have their SPNs registered in Active Directory SPN
    Example: If you have Nodinite on one SQL default instance and BizTalk in a two node cluster running the messagebox in its own instance, you register 7 SPNs in total (3 for the BizTalk default/named instance, 3 for the BizTalk Messagebox instance, and 1 for Nodinite)
If you are reading this text, chances are your SQL Server instances are running with accounts that do not have the right, upon service start, to register the SPN with Active Directory. This may happen if you are running the SQL Server instance with a local account, or a domain account that lacks the rights to register the service (SPN). If so, the latter is logged in the SQL Server audit log. read more here

Default instances

The following example registers accountname for the default SQL Instance using an elevated command prompt (requires AD domain rights):

setspn -S MSSQLSvc/myhost.redmond.microsoft.com accountname

Named Instances

The following example registers accountname for the named SQL Instance using an elevated command prompt (requires AD domain rights): repeat for each combination of named instance /accountname.

setspn -S MSSQLSvc/myhost.redmond.microsoft.com:instancename accountname

To validate what SPNs are registered for the account running the SQL Instance, execute the following command:

setspn -l accountname

DTC/MSDTC

Review the MSDTC user guide for additional information.

Next Step